SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / utility / 151 / aimtutor.doc < prev next >

Wrap

Text File | 1988-10-20 | 44.7 KB | 949 lines

A I M T U T O R I A L by Tom Hoeksma and Ad Herweijer Delft University of Technology Faculty of Applied Physics Pattern Recognition Group Lorentzweg 1 2628 CJ DELFT the Netherlands Introduction The image processing software package AIM (Atari Image Manager) has been developed at Delft University of Technology by Frans Groen (the 'image processor') and was adapted for the Atari ST computer in cooperation with Robert de Vries (the GEM program⑨ mer). Both were members of the Signal-/System-techniques Group in the Faculty of Applied Physics, Frans as a senior staff member and Robert as a graduate student. Recently, Frans changed jobs to become professor of Applied Informatics in the University of Amsterdam. AIM is designed to be an entry level 'appetizer' for the art of image processing. It gives the interested layperson an opportunity to acquaint himself with the techniques and terminology used in this dynamic field. The experiments described may be regarded as a lower bound of what can be accomplished with AIM, the upper bound being limited by the user's imagination only. This tutorial is not a full course on digital image processing. Such courses are frequently organized by the Pattern Recognition Group. For course information, please contact the Secretary of the Pattern Recognition Group, Faculty of Applied Physics, Lorentzweg 1, 2628 CJ Delft, the Netherlands, Phone 015-781416. Note that the operations used in the examples and demos cover a minor part of AIM's capabilities only. A comprehensive descrip⑨ tion of all the operations available is given in a file called AIMANUAL.DOC. Like this tutorial it is contained in a compressed file (DOCS_IMS.ARC), which can be found in the folder COMPRESS on the distribution disk (together with a decompressing program). Image processing is not particularly difficult; many people will have had their first image processing experience in the photographic darkroom. Note, however, that AIM, being dedicated to digital image processing, requires some basic knowledge of digital systems. So those of you who until now have successfully avoided learning about bits, bytes and binary numbers, be prepared to face the unavoidable! The 15 minutes or so spent on reading about these concepts will be richly rewarded by a better understanding of AIM's operations, if not by the deep admiration of your environment for the newly acquired vocabulary. AIM is a result of many years of research and development in the Pattern Recognition Group. Many of the image processing routines were contributed by (a.o.) Gert van Antwerpen, Frans Groen, Piet Verbeek, Ben Verwer, Lucas van Vliet and Igor Weber. This introduction was written (if not compiled from existing texts) by Tom Hoeksma and Ad Herweijer. Previous versions of AIM have already extensively penetrated the Atari ST community. However, as the documentation supplied with those first public domain versions was rather limited, the exploration of the software has been a mere 'image processing adventure' to most of the 'early birds'. The authors hope that this introduction, together with the related examples and demos included on the disk, will enable all prospective users (early birds and newcomers alike) to better understand what was, resp. is going on. Feedback plays an important role in the effective use of image processing as well as in software development. Therefore, we invite you to send your eventual comments and suggestions to: Prof. dr. ir. F.C.A. Groen c/o Delft University of Technology Faculty of Applied Physics Pattern Recognition Group Lorentzweg 1, 2628 CJ DELFT the Netherlands WHAT CAN WE EXPECT OF IMAGE PROCESSING? Maybe you have already had some experience with AIM or seen somebody else work with it. You may have wondered, then, how image processing could make features appear in the display that weren't there before the operation. Text that at first was unreadable, suddenly could be read easily; freckles in a girl's face, that didn't show in the original display, could (to her distress!) be counted after some appropriate keystrokes. You were perhaps convinced to have acquired a little magician, hidden in that tiny floppy disk. Be warned, however! Image processing can never reproduce features of the original image, that somehow have been lost. So, be prepared for surprises, but don't expect miracles! Image processing can enhance particular details in an image, but usually other details will have to be sacrificed. If 'A picture is worth a thousand words', image processing allows you to arrange those words to make the picture reveal its (secret) 'stories'. But remember: one picture's thousand words are different from another's. Every story will inherit the characteristics of the picture it was extracted from. The art of image processing is: to make the picture tell the one story that's useful to you. STAGES IN AN IMAGE PROCESSING APPLICATION In almost every image processing application we can recognize some stages, that eventually lead to the final result: recording, preprocessing, segmentation, postprocessing, analysis and inter⑨ pretation. Probably the most important stage is the recording of the original picture. As stated above, information that gets lost in the recording process can never be recovered. For the recording a video-camera is required, capable of converting the light, reflected from the object, into an electrical signal. As the video signal cannot be read directly by the computer, this signal must be sampled and digitized and the digital information must be transferred in an orderly manner to the computer's memory. This is done by a special piece of hardware, a so-called 'frame grabber'. Various frame grabbers are available for the Atari ST. In the Pattern Recognition Group monochrome and color frame grabbers have been developed that eventually will be made commercially available. After the image is stored in the computer it must be pre⑨ processed. Here the user tries to enhance or filter out particular wanted resp. unwanted features, to satisfy requirements of further analysis. Examples of preprocessing are the correction for changing grey values in the background (shading), suppressing noise, determination of edges in the image, etc. In order to be able to determine properties of single objects in the image, these objects must first be made detectable. If a grey value image contains dark objects on a light background, segmentation can, for instance, result in a binary image with white objects in a black background. Postprocessing can improve the result of the segmentation. Examples are the morfological (binary) operations. Holes in objects can be closed, edges peeled off, etc. In the analysis stage, measurements can be performed on the segmented objects. Examples: area, perimeter, curvature. In the interpretation stage the results of the measurements are evaluated. An 'intelligent robot' in a factory, that has to make a decision on whether he 'sees' a nut or a bolt, must be programmed to go through all stages mentioned here. Programming such a robot requires much intuition on how computers 'think'. An important requirement for the programmer is to be able to forget the way he would do the job himself! He must belong to the new breed of 'computer psychologists'. SOME TERMINOLOGY USED IN IMAGE PROCESSING Images and displays In image processing we must distinguish between 'images' and their 'displays'. In this context we define an image as the information that has been stored (as 1's and 0's) with a particular filename in the computer's memory or on a magnetic disk. A display is the representation of such an image on a video screen or -as a 'hardcopy'- on a piece of paper. An important property of an image is its information content. The information in an image depends on the presence of details (lines, edges, intensities, colors, etc.). Moreover, the information content determines the amount of computer memory required to store the image. Note that it's one thing to store an image accurately, but that it's another to display it with full conservation of information! The display hardware (video controller, monitor, printer, etc.) determines the degree to which the information in an image can be observed exactly. In image processing, there is a tendency to make the information content of stored images higher than can actually be displayed. This reduces the chance that the effects of rounding errors in intermediate results will deteriorate the final display. (Moreover, RAM-chips and floppy disks are much cheaper than display hardware!). AIM, for example, uses 64 kilobytes (kB) of RAM for the storage of images, whereas the Atari hardware can only handle 32 kB for the display of one screen (either monochrome or color). The basic element of an image is a pixel (picture element). To be observable on a display, a pixel must be attributed a grey value or color information. As an example, consider the Atari ST. In the monochrome (high resolution) mode the Atari ST supports the display of 2 grey values only. Each pixel (the Atari screen has 640*400 = 256,000 of them!) has a number ('0' or '1') associated with it that determines whether it is to be black or white: there is nothing in between. We will call this a 'binary display'. Note that terms like 'black', 'white' and 'grey value' in the context of monochrome displays actually refer to the color emitted by the phosphor used in the Cathode Ray Tube (CRT) of the display device (amber, green, white, etc.). Color images generally consist of three sub-images, displayed simultaneously. The sub-images represent the decomposition of the color image into three monochrome images (red, green and blue, respectively). The (visual) addition of the sub-images restores the original colors for the observer. Sub-images may be binary, but usually they have more than two grey values. An AIM color image, for example, has 256 possible grey values for each sub- image. In the color modes (medium-, resp. low-resolution), the ST is capable of displaying 8 grey values for all three primary colors. Consequently, there are 8*8*8 = 512 different combinations, each combination representing another color. Such a group of available colors is called a palette. The palette represents all possible states that an individual pixel may have. Each combination of red, green and blue intensities is perceived with a particular brightness, the luminance. Luminance information can be used for the display of color images on a monochrome monitor; AIM allocates an extra sub-image for it. If a pixel has equal intensities for red, green and blue , it will display the color 'grey'. Thus, in the palette of the med- res and lo-res color modes there are 8 levels of grey, extending from black (R=G=B=min=0) to white (R=G=B=max=7). Very often the property of a color monitor to display grey values (as opposed to just black or white) is more important to the user than its capability of displaying colors! As we have seen above, in binary images each pixel can have 2 grey values only. We say that each pixel has 1 'bit' (binary digit) of information associated with it. Equivalently, in color images the information per pixel is higher; AIM uses 32 bits of color and grey value information. We will return to this shortly. Pixels and neighbors. An AIM image can be visualized as a 'checkerboard' with 256*256 or 128*128 square fields (for monochrome and color images, respectively). Each field corresponds to a pixel carrying 8 bits (= 1 Byte) of grey value information or 32 bits (= 3+1 Bytes) of color and luminance information. Pixels, being neatly arranged in a square raster of rows and columns, have neighbors. The number of neighbors of a particular pixel is referred to as its connectivity. On a checkerboard neighbors can be defined as having either just sides, or sides as well as corners, in common with the reference pixel. Depending on these definitions the connectivity of pixels on a square raster is 4 or 8. Pixels sometimes are arranged hexagonally. In such a 'honeycomb configuration' the connectivity is 6. Image processing routines can be divided into three groups: point, local and global operations. Point operations use the information of one single pixel in the input image to calculate the result for a corresponding pixel (not necessarily the same) in the output image. An example is the INVERT operation, where the intensity bit for every pixel in the (binary) image is reversed. In a local operation the result for one single pixel of the output image is determined by the original pixel and its neighborhood. An example of such an operation is Lmin ('Local minimum'), where the output pixel gets the minimum grey value of its neighborhood (including itself) in the input image. This operation extends dark parts in the image. The neighborhood of interest can often be specified (i.e. 1*3, 3*3, 5*5, etc.). In AIM the neighborhood can only be an odd number. In global operations the result for one single output pixel is derived from the information of all pixels in the input image. One example of a global operation is the Fourier transform, used to determine periodic features in the image. Fourier transforms are not supported in this version of AIM. PROPERTIES OF THE ATARI ST VIDEO HARDWARE Almost all of AIM's images will probably have to be displayed on a video monitor (either monochrome or color). However perfect an image may be, it will eventually have to pass the bottleneck of the computer's video display hardware. Much of the effort of programming AIM has been devoted to overcoming inevitable limitations of a computer's display hardware. For a correct interpretation of the results, we will extend briefly into some details of the hardware used by the Atari ST for the control of displays: video display memory, video controller and monitors. The video display memory. The central part of the display hardware is the video display memory. Independent of the resolution chosen (lo-, med-, hi-res), the Atari ST allocates 32 kB (= 256,000 bits) of RAM for storage of the information of one screen. In the high resolution mode 640*400 = 256,000 pixels can be displayed, leaving just one bit/pixel for grey value definition. As a result only binary images can be displayed on a monochrome monitor. As explained above, a color image requires more than 1 bit of memory per pixel. You may wonder how the ST manages to attribute more than 1 bit to a pixel if in the hi-res mode (1 bit/pixel) all the available 32 kB is used up already! The answer to this question can be intuitively found from the terms 'medium-resolution' and 'low-resolution' for the color modes. In these modes, the spatial resolution of the hi-res mode, 640*400 = 256,000 pixels, is sacrificed in order to give the pixels more luminance (monochrome displays on color monitors) or color information. By reducing the resolution to 640*200 = 128,000 (med-res) or 320*200 = 64,000 pixels (lo-res), the pixels can be attributed 2 or 4 bits for luminance or color definition. This allows palettes of 4 or 16 colors to be defined in the med- res or lo-res mode, respectively. Thus, the video display memory may be thought of as representing: 1 binary image of 640*400 pixels (hi-res) 2 binary images of 640*200 pixels (med-res) 4 binary images of 320*200 pixels (lo-res). The color of a particular pixel is determined by the (weighted) bit-values of the 2/4 corresponding pixels in the binary images. The video controller. The next stop on our journey from the video display memory to the monitor screen is the video controller. This chip takes care of all the housekeeping, required for conversion of the bytes in the video display memory to 'real world' voltages, compatible with the intensity input(s) of the monitors. Since in the hi-res mode the pixels contain just 1 bit of grey value information, the video controller incorporates a very simple 1 bit 'A/D converter' to generate the intensity signal for the monochrome monitor. We have seen that, as a consequence of the limited 32 kB of video display memory, in the med-res and lo-res modes the pixels can have just 2/4 bits of color information. This would allow for palettes of 4/16 colors. Fortunately, Atari has made the ST much more versatile, generously including three 3 bit A/D converters in the video controller. Thus, for each primary color there are 8 grey values available, allowing a palette of 8*8*8 = 512 colors. If the pixels contain information for the definition of 4/16 colors only, how does the video controller know what colors to choose from the palette of 512? The answer is in the operating system; it has facilities to define a 'sub-palette' of 4/16 colors. Each color in the sub-palette represents a particular combination of grey values for red, green and blue . These combinations are stored in a lookup table of 4/16 elements. The 2/4 bit color information for each pixel refers to a position in this lookup table and the video controller converts the RGB- combination stored there into the corresponding intensity control voltages. When a color monitor is used to display a monochrome grey value image, the operating system automatically loads the lookup table with 4/8 (why not 16?) grey combinations for med-res or lo-res displays, respectively. The monitors. Basically, a video monitor consists of a CRT with some electronic circuitry to control the deflection and the intensity of the electron beam. A monochrome monitor uses one electron beam. A color monitor requires three beams, one for each primary color. For intensity control the monitors have 1 or 3 inputs. The voltage on these inputs determines the intensity of the lightspot on the screen. Note, that in principle both monochrome and color monitors are capable of displaying grey values: there is a continuous range over which the intensities can be controlled. However, as we have seen, the other display hardware reduces the number of possible grey values and/or colors considerably. The deflection of the electron beam(s) is controlled by the monitor itself; for synchronization it needs a triggering signal ('sync') which is produced by the video controller and simply added to the intensity signal(s). AIM IMAGES AND THEIR DISPLAY ON THE ATARI ST MONTORS The AIM workspace allows simultaneous storage of 4 images: A, B, C and D. Each image (monochrome or color) occupies 64 kB. A monochrome image (stored on disk with the extension .IM) consists of 256*256 pixels, having 8 bits of grey value information (i.e. 256 grey values possible). Color images (extension .COL) consist of 128*128 pixels, having 24+8=32 bits of color and luminance information. For the display of color images AIM supports the ST's lo-res mode only (320*200 pixels with a palette of 16 colors). You may have wondered why AIM uses 4 Bytes of information for pixels of .COL images. Wouldn't a color image be perfectly defined by just using 1 Byte for each color sub-image? The answer is: yes, it would. For technical reasons, however, we have chosen to add en extra byte for luminance definition. This format allows, for example, the monochrome display of .COL images. We will discuss the display of AIM images in 4 different situations: Monochrome (.IM) images - monochrome display (hi-res) Color (.COL) images - monochrome display (hi-res) Monochrome (.IM) images - color display (lo-res) Color (.COL) images - color display (lo-res) Monochrome (.IM) images - monochrome display (hi-res). As an extension to our checkerboard model we might introduce a stack of 8 checkers placed on each field, representing the 8 grey value bits of the corresponding pixel. A white checker represents a '1', a black one a '0'. Depending on its position in the stack the weight of a white checker (i.e. the contribution to the grey value) is 128, 64, 32, 16, 8, 4, 2 or 1. Thus, if the lower three and the upper two checkers are white, the corresponding grey value is (128+64+32+0+0+0+2+1=) 227. In our model we have 8 horizontal planes of 256*256 checkers, each plane contributing its own weight to the total image. Note that each plane itself actually corresponds to a binary image, hence the name: bitplanes. The upper plane (b1) is the least significant bitplane, the lower plane (b8) is the most significant one. In AIM the 8 bitplanes of a grey value image can be processed as 8 separate binary images. Bitplanes of one image can be copied (command: BCOPY) to one or more arbitrarily chosen bitplane(s) of an other. Using this facility, a grey value image can be used as a (temporary) storage for 8 independent binary images. As determined by the ST hardware, in the hi-res mode only binary images can be displayed. AIM circumvents this limitation by using a trick called sigma-delta technique: the 256 grey values available in the image are represented as well as possible by dot densities in the display. This yields a 256*256*1 bit display with a reasonable suggestion of grey values to the human eye. A special situation occurs if we want to process monochrome pictures from the drawing package DEGAS. Monochrome DEGAS pictures (extension .PI3), being binary 640*400 pixel images, cannot be processed directly by AIM. When read from a disk these images are converted to a 320*200 pixel image with 5 levels of grey information. The 640*400 pixels are grouped in 320*200 non- overlapping 2*2 fields. Each pixel in the final 320*200 pixel image is attributed the average grey value of the corresponding 2*2 field: 0 pixels white -> grey value: 0 1 pixels white -> grey value: 63 2 pixels white -> grey value: 127 3 pixels white -> grey value: 191 4 pixels white -> grey value: 255 Subsequently, the converted DEGAS images get the same sigma-delta treatment as the regular .IM images for the display of grey values. Note that in this process information is lost; the resulting image has less than 320*200*3 = 192,000 bits of information (originally: 256,000 bits). Consequently, even though AIM can re-convert (loosing information again!) these images back to DEGAS format, the original pictures can never be recovered completely. Color (.COL) images - monochrome display (hi-res). For the display of a .COL image on a monochrome monitor, only the 128*128 pixel luminance sub-image is used. The sigma-delta technique again converts this luminance information to dot densities. Monochrome (.IM) images - color display (lo-res). Monochrome (.IM) images have 8 bits (256 levels) of grey value information. When an (.IM) image is read from disk in the lo-res mode, AIM will load the 16 color palette with the maximum of 8 levels of grey and applies the sigma-delta technique to interpolate between these 8 levels. Color (.COL) images - color display (lo-res). For the display of .COL images in the lo-res mode AIM first determines an optimum palette of 16 colors from the palette of 256*256*256 colors available in the original image. The 8 bits of luminance information is not used. The palette for a particular screen is derived from the image in the active window only; this may not be the optimum palette for other images displayed simultaneously. In this mode color pictures from the DEGAS and Neochrome drawing packages (extensions .PI1 and .NEO, resp.) can be read by AIM also. Again, size reduction (to 160*100 pixels), grey value attribution and the sigma-delta technique are applied for the processing and display of these images. IMAGE PROCESSING CAPABILITIES OF AIM The image processing software package AIM has been written in the C language, using the Mark Williams C-compiler. It makes extensive use of the GEM window structure for the user interface and the display of images. AIM allows processing and display of monochrome, binary and grey value images as well as of color images. It has an interface (via the Atari ST's DMA bus) to monochrome and color frame grabbers, developed in the Pattern Recognition Group. The user interface. Image processing operations can be chosen from drop-down menues, using dialog boxes, as well as by typing the appropriate command in the command box. In any case the commands are transferred as strings by the Window Management System to the Command Interpreter. Many of the AIM commands cannot be invoked from drop-down menues. They will be designated by an asterisk (*). The command interpreter starts the image processing routine. It is not necessary to type the complete command name; any number of characters that doesn't give ambiguities will do. Sequences of commands may be combined in a command file or macro. Command files can be nested to 16 levels. They are automatically created by activating the Logging feature; any operation you perform after 'Logging' is checked, will be logged. Macros can be saved to disk for re-use. The extension for the filename is .AIM. A macro is executed by typing the name (without extension), preceded by the character '@'. Clicking the menu-entry Macro and the name in the dialog box will do the same. Pausing the execution is possible by hitting the Esc-key. Proceed with the macro by hitting Return or stop by clicking in the appropriate box. The commands in the Command Window can be edited simply. Delete and backspace work like in most wordprocessors. Control-X deletes a whole line. All characters typed after a star (*) will be ignored by the command interpreter and thus can be used for comments. Typing a question mark (?) and <Return> will display a list of available operations. The syntax and a short explanation for the commands can be found in Help-files. Choose HELP!!! in the Utilities menu. Note, however, that this version (2.5) of AIM has been extensively revised. Many operations have been added and some of the existing operations allow more parameters to be specified than those given in the current Help-files and dialog boxes. Fortunately, all operations are upward compatible. The AIMANUAL.DOC in the COMPRESS folder contains an updated description of all the available operations. EXAMPLES AND DEMOS The examples on the AIM disk are self-explaining. The only prerequisite is a reasonable understanding of the previous chapters. Because the disk space was limited, we could only include some of the most relevant examples. Consequently they cover just a few of the possible operations; most of the operations will have to be explored by yourself! The commented command files EXAM1.AIM -> EXAM5.AIM have been included so that you can check your manually entered exercises. Besides the prepared examples three extra demos (macros) have been included on the disk: DEMOCER.AIM, DEMOHFE.AIM and DEMOSCH.AIM. They contain some operations and strategies that may be of interest to you after having completed the examples successfully. Finally two exercises are added to (self-)test your abilities. If things go totally wrong, don't feel embarrassed by peeping into the macros PRAK1.AIM and PRAK2.AIM; they contain possible solutions for these exercises. The exercises are compressed files and can be found in the folder COMPRESS. In case you missed a point: in a grey value image 'black' corresponds with a value 0, 'white' with a value 255. In a binary image (or a bitplane of a grey value image) these values are 0 and 1, respectively. All examples and exercises will work in both modes, lo-res color and hi-res monochrome. For binary operations a monochrome monitor is recommended. Some demos are more impressive in color, though! Example EXAM1.AIM Operations used: Histogram, Equalize First we will retrieve the image MOON.IM. Click the entry 'Read Image' under the 'File' menu. The defaults in the selector box that pops up ('Window: A' and 'STANDARD') are acceptable, so click 'OK' (or hit the Return key). Those of you who prefer a command line interpreter might as well type in 'read A' instead of using the mouse. Next a GEM 'ITEM SELECTOR' appears. Choose 'MOON.IM' and after a few seconds a picture appears in Window A, that shows the foot of moonlander surounded by moondust. You will agree that, normally, you would throw such a picture in the trashcan and probably declare the mission to the moon a flop. AIM can help you deal with such frustations! Just to get a feel of the power accumulated in that tiny 3.5", try the operation 'Equalize' under the menu 'GreyOps'. Choose A as the input image and B as the output. Looks better, doesn't it? Remember, the information was already in the image; even without AIM the mission to the moon wasn't in vain! But the application of AIM certainly adds to the succes. To understand what has happened to the original image, try the entry 'Histogram' under 'Utilities'. This will show a graph of the frequency of occurrence of a particular grey value (or rather: a small range of grey values) in the image, plotted against the grey value. Frequencies are plotted vertically, grey values (0 -> 255) horizontally. The histogram indicates that the grey values in the original image were concentrated in a relatively small range (centered around grey value 50). From the histogram we can conclude that the grey scale from 0 to 255 has not been used efficiently; nearly all pixels have a grey value between, say, 25 and 75. The result is that, in a way, we are looking at the printing on a toy balloon; only if we inflate the balloon some of the smaller details will show. If somehow we could stretch the original grey value range, so that 25 would shift to 0 and 75 to 255, the same effect might be imposed on our moon image. Throwing away the ranges 0 ->25 and 75 -> 255 doesn't do much harm, because little information will be lost. Equalization is the air pump that inflates a grey value range. Unlike an air pump (and the suggestion in the previous paragraph!) it does so intelligently. That is, the stretching effect on a particular range of grey values depends on the height of the histogram for that range. Ranges with high values in the histogram will be expanded at the cost of the compression of less prominent ranges. Note, that there may be multiple peaks and valleys in the histogram. To see what we mean, determine the histogram of image B and compare it with the original one. The frequencies (vertical lines) are divided more evenly over the available range of grey values. Ranges with high frequencies of occurrence in the original histogram have been stretched and those with low frequencies compressed. If you are not completely satisfied, perform the same operations on the image TRUI.IM, which has multiple peaks in the histogram. Equalization is a nice example of image processing: important features (in this case grey value ranges) are emphasized at the cost of less important features. Yet, in this particular operation no information is lost; a 'de-emphasis' procedure (not available in AIM) could restore the original image. Hint: if you want to get rid of the histogram in a particular display, use 'Gdisplay' in the Utilities menu. Example EXAM2.AIM Operations: Gradx, Grady, Enhance Read the image TRUI.IM in (the default) Window A. This image has become a kind of reference for many groups involved in image processing. Perform the operation 'Gradx' in the GreyOps menu. Accept all the defaults proposed by AIM. Worry about the Multiply and Add values later, or better still, experiment with them. The Gradx ('gradient in x-direction') operation determines the rate at which grey values change in the original image and attributes corresponding grey values to the pixels of the output image. An output pixel gets a grey value according to the formula: grey-out = (gradient-in) * Multiply/1024 + Add. This operation shows vertical edges in the image. An edge corresponds to a step in grey value. Note the effect on edges in the girl's hat. Now perform Grady. This time send the output to Window C. Note the result for horizontal edges (mouth, eyebrows, etc.). A related operation, which is generally used to sharpen-up pictures is the Enhance-operation (in menu GreyOps). It determines the second derivative (in both directions) of the grey-values in the input image. Like Gradx/y it emphasizes high frequencies in the image. High frequencies occur at sharp edges. Try the Enhance filter on the original TRUI.IM. and enjoy the improvement. But what did we do to her eyes? Seems we created her contactlenses... Example EXAM3.AIM Operation: Median filter Read image BNOISE.IM. This image has intentionally been degraded by 'shot noise'. This type of noise occurs often in the transmission of signals. Some of the pixels differ very much in grey value from the surrounding pixels. In this case they are white. We want to use filtering to remove the noise. Usually it is difficult to predict the effects of filtering. Various parameters must be specified, requiring much intuition. Try, for example the entry 'Filter' in the GreyOps menu! A good filter for the problem of shot noise is the so-called median filter. In this operation AIM determines the grey values in 3*3 neighborhoods for each pixel in the input image. These values are sorted in tables with 9 entries. The 5th entry in each table (the 'median') becomes the grey value of the corresponding output pixel. The grey value of a shot noise speck is likely to be in the extremes of the tables in which it appears, and thus it will be removed. Perform the operation 'Median' in the GreyOps menu. Only a few stubborn noise specks will survive. They may be removed by a repeated application of this filter. Example EXAM4.AIM Operations: Copy, Lmin, Lmax, (*)mindev, Gdisplay Once more we call on TRUI.IM; read it from disk. We will need a second copy of this image in Window B. There are two options: a. Read the image again from disk and have AIM put it in Window B b. Use 'Copy' in menu GreyOps to copy Window A in Window B. Note that there is a 'Copy' entry in the BinOps menu too. This binary operation copies only bitplanes, as opposed to a grey value copy, which copies all 8 bitplanes of an image at once. If all went well, you now have the fabulous Trui twins on screen. The first operation to be performed is 'Lmin' in the GreyOps menu. This operation looks for the lowest grey value in an n*n neighborhood (n to be specified by the user) of the input pixel and attributes it to the corresponding output pixel. This filter has a tendency of expanding darker areas in the image. Try it with n=9 and put the result in Window C. Experiment a little with different values for n. Observe the effects on nostrils and eyes! In any case end with a 9*9 Lmin-ned TRUI.IM in Window C. Next apply the 'Lmax' filter on Window A. Choose n=9 and put the result in Window D. This filter expands lighter area's in the image. We hope that until now you acquired enough intuition to be able to predict the effect: gone are those nostrils and gone is that mouth in the 'lighter shade of pale' that surrounded them. But now the real image processor arises. We are going to use an operation that uses three input images: (*)mindev C,D,A. This operation compares corresponding pixels (i.e. pixels with the same coordinates) in the original image (A) and the two other images (C and D). The output pixel gets the grey value of the corresponding pixel in C or D, depending on which one of the two is closest to the grey value in A. Big deal, but what is the effect? Let's try it first. The (*)mindev ('minimal deviation') operation cannot be invoked from the menu, so we have to type it in de Command Window: type mindev C,D,A <Return>. The result will be shown in Window A. Compare it with the original image, which is still luring in Window B. Apparently the edges in the image (cheeks, hair) have been sharpened. The net effect of Lmin, Lmax and mindev is, that near edges there is a backlash in grey value. In other words, grey values are reluctant against changes; changes occur suddenly as a function of position. Example EXAM5.AIM Operations: (*)Clear, Threshold, Invert, Propagation, Bdisplay, Reset, Exor and (*) Measure. Read the image CERMET.IM from disk. Our purpose with this example is to do some measurements on the objects in this image. The '(*)Measure' operation requires the objects of interest to be white in a black background. In the menu 'BinOps' we have some useful operations at our disposal to achieve that goal. In order to be able to apply binary operations ('BinOps'), we first will make the grey value image in Window A binary. The operation 'Threshold' in the GreyOps menu makes pixels with a grey value below the threshold black and pixels with a grey value above it white. When the operation is invoked, it proposes a threshold which is the average grey value in the image; it is not necessarily the best guess, but usually it yields satisfactory results. Stop! The Threshold operation will ask for the bitplane where the binary image is to be stored (it defaults to b1 in Window B). However, as our previous exercises will have left some garbage in the other bitplanes of Window B, we first have to clear those. The operation '(*)Clear' is provided to clear all bitplanes of a window at once (clear = grey value 0 = black!). Type: clear B <Return>. Now we are ready for the Threshold operation; click on it in the GreyOps menu and accept the defaults. As we need white objects in a black background, the picture in Window B must be inverted. Click on 'Invert' in the BinOps menu (accept the defaults). Note that some of the objects near the frame of the window are only partially displayed. We don't want the '(*)Measure' operation to take these incomplete objects into account, but how can we get rid of them? How can we distinghuish them from complete objects? The answer is: use the 'Propagation' operation (in CelOps) . The 'Propagation' operation allows us to isolate objects. White pixels (called 'seeds) will 'grow' (expand) under the condition that in a given reference bitplane (the 'mask') the corresponding pixels are white too. We can visualize this operation as taking place in a field with seeds (= white pixels that we want to grow to shapes present in the mask). The reference bitplane (the 'mask') is the culture medium; it has fertile and infertile regions. If a region is fertile (i.e. it has white pixels that coincide with the seed pixels), the seed can grow. In one 'iteration' (propagation step) a pixel grows in accordance with its connectivity: one white pixel is added in all connecting directions. In AIM the seed bitplane is called CLP (Cellular Logic Plane). In the next iteration the seed bitplane (CLP) that resulted from the first iteration is compared once more with the mask bitplane. Coinciding white pixels in CLP and mask will, once more, grow. This will continue until all seeds have grown to the edges of the fields in the mask; we have created an exact copy of all the fields that in the first iteration coincided with at least one seed. The trick of isolating particular fields in the mask is to create a CLP with seeds that coincide with those fields. Let's return to our problem of isolating the incomplete white objects at the borders of bitplane b1 in Window B. It would be nice if we had a bitplane available (to be used as the CLP) with white pixels along the frame only. The Propagation operation would make those border-pixels grow to the exact shapes of the intersected objects in the mask (in our case: b1). The result would be: two images having the unwanted objects in common. Subsequent application of the logical operation 'Exor' (in the BinOps menu) on these two images will finally remove the unwanted objects. Exor is the inequality operator: it compares corresponding pixels in both (binary!) images and outputs a white pixel if (and only if) they are different. Now that we hopefully understand it we cannot wait to put our knowledge to the test. The only image we need is bitplane b1 in Window B. Click on Propagation. We will have to change almost all of the defaults! Our mask bitplane is b1 instead of the proposed b2. Furthermore, we will use b2 as our CLP instead of b1. The connectivity is not important, but change it to 8. The necessary white edge for our CLP can be chosen with the entry 'Edge value'. Choose 1 (for white). Make the number of iterations 100; that is too many, but AIM will stop automatically when all growth has stopped. Check all entries in the Dialog Box: if something is wrong there is a risk that you have to start all over again! Your ST won't complain, but we don't want to frustrate prospective image processors in such an early stage. Hit Return. If all is well, you will see an image in bitplane b2 of Window B that has the intersected objects only. Wrong? Don't worry, just keep trying. Don't forget to clear bitplane b2 prior to every Propagation operation. Next invoke operation Exor (in BinOps). Use b1 and b2 in Window B as inputs and b3 as output. At last our image is ready for the (*)Measure operation. This operation assumes that the image is in b1 of Window B, so we must copy b3 to b1 first. Click 'Copy' in BinOps and choose the appropriate bitplanes. (*)Measure performs a number of measurements on the objects and displays the results in the Command Window. It assigns numbers to the objects (left -> right, up -> down) and labels each object with a grey value according to this number. This can be observed in Window D. Type measure (mea will do!) <Return>. Note that the Command Window can be sized to bring all measured data on screen. PRACTICAL EXERCISES PRAK1. Study the image PRAK1.IM. Your assignment is to separate the nuts from the bolts. In other words: use AIM to generate two images, one containing the nuts (including the one that rests on its side!) and the other one the bolts. Count the objects afterwards. PRAK2. The image PRAK2.IM shows a handful of electronic components. Try to separate them. Use your fantasy and surprise husbands, friends and neighbors!